14. 보안의 기본과 개념1

73. 보안의 기본과 개념

정보 보안의 CIA 밸런스

CIA 원칙: 정보 보안을 구성하는 세 가지 핵심 요소

정보 보안의 3요소 (CIA Triad):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

     [CIA 원칙]
         │
    ┌────┼────┐
    │    │    │
    ↓    ↓    ↓
  [C]  [I]  [A]

Confidentiality (기밀성)
└─ 적법한 사람만 정보 이용
└─ 무단 접근 방지

Integrity (무결성)
└─ 정보의 정확성 유지
└─ 변경/파괴 방지

Availability (가용성)
└─ 필요할 때 정보 이용 가능
└─ 서비스 지속성 보장

CIA 요소 간 상충 관계:

CIA 밸런스의 트레이드오프:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[기밀성 ↑]     [무결성 ↑]
      \           /
       \         /
        \       /
         \     /
          \   /
           \ /
            ↓
      [가용성 ↓]

보안 강화:
• 엄격한 접근 제어
• 다단계 인증
• 암호화 강화
  ↓
• 이용 절차 복잡
• 응답 시간 증가
• 사용성 저하

균형이 핵심:
→ 조직의 특성과 요구사항에 맞는 적절한 균형점 찾기

조직별 CIA 우선순위 예시:

정보 보안을 검토하는 절차

3단계 보안 검토 프로세스:

정보 보안 검토 프로세스:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1단계: 자산 식별
    ↓
[보호 대상 자산 파악]
• 무엇을 지켜야 하는가?
• 어떤 가치가 있는가?
    ↓

2단계: 위험 분석
    ↓
[위험과 위협 나열]
• 어떤 위협이 존재하는가?
• 발생 가능성과 영향도는?
    ↓

3단계: 대응 방안 수립
    ↓
[대책 마련]
• 기술적 대책
• 관리적 대책
• 물리적 대책

1단계: 보호 대상 자산 식별

개인이나 조직에서 지켜야 할 가치가 있는 것이 무엇인지 구체적으로 결정해야 함

보호해야 하는 자산의 예시:

보호 대상 자산:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[무형 자산]
├─ 신용 (Reputation)
├─ 브랜드 (Brand)
├─ 특허 (Patent)
└─ 저작권 (Copyright)

[정보 자산]
├─ 고객 정보 (Customer Data)
├─ 경영 정보 (Business Intelligence)
├─ 영업 비밀 (Trade Secrets)
└─ 개인정보 (Personal Information)

[물리적 자산]
├─ 자금 (Funds)
├─ 시설 (Facilities)
└─ 장비 (Equipment)

2단계: 위험과 위협 파악

자산이 직면한 위험과 위협을 체계적으로 나열하고 분석함

위험과 위협의 예시:

보안 위협 분류:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[환경적 위협]
├─ 자연재해 (지진, 화재, 홍수)
├─ 사고 (정전, 장비 고장)
└─ 테러 (물리적 공격)

[인적 위협]
├─ 정보 누설 (Information Leak)
├─ 내부 범행 (Insider Threat)
└─ 신용 훼손 (Reputation Damage)

[기술적 위협]
├─ 사이버 공격 (Cyber Attack)
├─ 멀웨어 (Malware)
├─ 랜섬웨어 (Ransomware)
├─ 피싱 (Phishing)
└─ 표적형 공격 (APT)

[법적/규제 위협]
└─ 법 개정 (Regulation Change)

3단계: 대응 방안 검토

나열한 위협에 대해 구체적인 대응 방법을 수립함

보안 대책 유형:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[기술적 대책]
├─ 방화벽 (Firewall)
├─ IDS/IPS (침입 탐지/차단)
├─ 암호화 (Encryption)
├─ 접근 제어 (Access Control)
├─ 백업 시스템 (Backup)
└─ 네트워크 강화 (Network Security)

[관리적 대책]
├─ 보안 정책 수립
├─ 사용자 교육
├─ 권한 관리
├─ 감사 및 모니터링
└─ 사고 대응 절차

[물리적 대책]
├─ 출입 통제
├─ CCTV 설치
├─ 잠금 장치
└─ 백업 센터

사전 대책 vs 사후 대응:

보안 대응 시점:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[사전 대책 (Preventive)]
    ↓
위협 발생 방지
• 방화벽 설치
• 암호화 적용
• 접근 권한 통제
• 보안 패치
    ↓
[위협 발생]
    ↓
[사후 대응 (Reactive)]
    ↓
피해 최소화 및 복구
• 사고 대응 팀 가동
• 침해 범위 파악
• 시스템 격리
• 백업 복구
• 법적 대응

보안 검토 프로세스 실무 예시

전자상거래 기업의 보안 검토:

실무 예시: 온라인 쇼핑몰
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. 자산 식별:
   ├─ 고객 개인정보 (이름, 주소, 전화번호)
   ├─ 결제 정보 (신용카드 번호)
   ├─ 구매 이력
   ├─ 브랜드 신뢰도
   └─ 웹사이트 가용성

2. 위험 분석:
   ├─ SQL 인젝션 공격
   ├─ 개인정보 유출
   ├─ DDoS 공격 (서비스 중단)
   ├─ 내부자에 의한 정보 유출
   └─ 개인정보보호법 위반

3. 대응 방안:
   ├─ 기술적: WAF, DB 암호화, CDN
   ├─ 관리적: 보안 교육, 권한 분리
   └─ 물리적: 서버실 출입 통제

결과:
→ CIA 밸런스 유지
→ 고객 신뢰 확보
→ 법적 리스크 최소화

74. 멀웨어/컴퓨터 바이러스

컴퓨터 바이러스와 멀웨어의 차이

용어의 변화:

용어의 진화:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[과거]
"컴퓨터 바이러스"
    ↓
모든 악성 코드를 통칭
    ↓

[현재]
"멀웨어 (Malware)"
    ↓
Malicious Software
악의적인 소프트웨어 전체
    ↓

컴퓨터 바이러스는
멀웨어의 하위 분류 중 하나

컴퓨터 바이러스의 3대 특징:

컴퓨터 바이러스의 특징:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. 자기 전염 기능 (Self-replication)
   └─ 스스로 복제하여 다른 파일로 전파
   └─ 기존 프로그램에 기생

2. 잠복 기능 (Latency)
   └─ 일정 기간 증상 없이 숨어있음
   └─ 특정 조건 만족 시 활성화

3. 발병 기능 (Payload)
   └─ 실제 피해를 발생시키는 동작
   └─ 데이터 파괴, 정보 유출 등

특징:
→ 단독으로 존재 불가
→ 반드시 다른 프로그램에 기생

자기 전염 기능 상세:

자기 전염 메커니즘:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[감염된 프로그램.exe]
    ↓
[바이러스 코드가 실행]
    ↓
[시스템 내 다른 실행 파일 검색]
    ↓
[정상 파일 A.exe] → [바이러스 코드 삽입] → [감염된 A.exe]
    ↓
[정상 파일 B.exe] → [바이러스 코드 삽입] → [감염된 B.exe]
    ↓
[확산]

발병 기능 예시:

바이러스 발병 행위:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[데이터 파괴형]
├─ 파일 삭제
├─ 디스크 포맷
└─ 부팅 영역 파괴

[정보 유출형]
├─ 키로깅
├─ 화면 캡처
└─ 파일 외부 전송

[시스템 마비형]
├─ CPU 과부하
├─ 메모리 고갈
└─ 네트워크 마비

악영향을 미치는 멀웨어 종류

멀웨어 주요 유형:

멀웨어 분류 (전염 방식 기준):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[컴퓨터 바이러스 (Virus)]
├─ 자기 전염: O (기생형)
├─ 잠복 기능: O
├─ 독립 실행: X
└─ 특징: 기존 프로그램에 기생하여 전염

[웜 (Worm)]
├─ 자기 전염: O (독립형)
├─ 네트워크 전파: O
├─ 독립 실행: O
└─ 특징: 네트워크를 통해 독립적으로 확산

[트로이 목마 (Trojan Horse)]
├─ 자기 전염: X
├─ 위장: O (정상 프로그램으로 가장)
├─ 독립 실행: O
└─ 특징: 사용자를 속여 직접 실행하게 함

[스파이웨어 (Spyware)]
├─ 자기 전염: X
├─ 정보 수집: O
├─ 은밀 동작: O
└─ 특징: 사용자 활동 감시 및 정보 유출

각 유형별 상세:

1. 컴퓨터 바이러스 (Virus):

컴퓨터 바이러스 동작 방식:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[정상 프로그램]
    ↓
[바이러스 감염]
    ↓
[감염된 프로그램 실행]
    ↓
    ├─→ [정상 기능 수행]
    └─→ [바이러스 코드 실행]
            ↓
        [다른 파일로 전염]
            ↓
        [잠복]
            ↓
        [조건 만족 시 발병]

특징:
→ 숙주 프로그램 필요
→ 사용자가 감염 파일 실행 시 활성화

2. 웜 (Worm):

웜의 확산 메커니즘:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[PC A] ←───┐
  │        │
  ↓        │
[웜 실행]    │
  │        │
  ↓        │
[네트워크 스캔]
  │        │
  ↓        │
[취약점 발견] │
  │        │
  ↓        │
[PC B로 전파]──┘
  │
  ↓
[독립적으로 확산]

대표 사례:
• 2003년 SQL Slammer
  → 인터넷을 통해 10분 만에 75,000대 감염
• 2017년 WannaCry
  → 150개국 30만대 감염

3. 트로이 목마 (Trojan Horse):

트로이 목마 침투 과정:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[정상 프로그램으로 위장]
    ↓
예시:
• "무료 게임.exe"
• "중요 문서.pdf.exe"
• "보안 업데이트.exe"
    ↓
[사용자가 직접 실행]
    ↓
[정상 기능처럼 동작]
    ↓
[백그라운드에서 악성 행위]
├─ 백도어 설치
├─ 정보 유출
└─ 추가 멀웨어 다운로드

주의:
→ 자기 전염 기능 없음
→ 사용자의 실행이 핵심

4. 스파이웨어 (Spyware):

스파이웨어 동작 흐름:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[은밀한 설치]
    ↓
[백그라운드 실행]
    ↓
[정보 수집]
├─ 키보드 입력 (Keylogging)
├─ 마우스 클릭
├─ 화면 캡처
├─ 웹 브라우징 기록
└─ 파일 접근
    ↓
[수집된 정보 외부 전송]
    ↓
[공격자 서버]

목적:
→ 개인정보 탈취
→ 금융 정보 수집
→ 기업 기밀 유출

멀웨어 기능별 분류

기능별 멀웨어 유형:

멀웨어 기능별 분류:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[다운로더 (Downloader)]
역할: 공격자 서버에서 멀웨어 본체 다운로드
특징: 초기 침투용 소형 프로그램
    ↓

[키로거 (Keylogger)]
역할: 키보드 입력 감시 및 기록
목표: 비밀번호, 신용카드 정보 탈취
    ↓

[랜섬웨어 (Ransomware)]
역할: 데이터 암호화 후 금전 요구
특징: 암호 해제 대가로 비트코인 요구
    ↓

[백도어 (Backdoor)]
역할: 정상 인증 우회하는 뒷문 생성
목적: 지속적인 접근 권한 확보
    ↓

[RAT (Remote Access Trojan)]
역할: 원격 조작 및 데이터 탈취
기능: 완전한 시스템 제어
    ↓

[루트킷 (Rootkit)]
역할: 침입 도구 세트
특징: 존재 자체를 숨김
    ↓

[익스플로잇 (Exploit)]
역할: 시스템/앱 취약점 공격
목적: 권한 획득 또는 코드 실행

각 유형 상세 설명:

다운로더 (Downloader):

다운로더 공격 시나리오:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[피싱 이메일] → [첨부파일 실행]
    ↓
[소형 다운로더 실행]
파일 크기: 수십 KB
    ↓
[C&C 서버 접속]
(Command & Control Server)
    ↓
[실제 멀웨어 다운로드]
파일 크기: 수 MB
    ↓
[시스템 감염]

장점 (공격자 입장):
→ 초기 페이로드 작음
→ 탐지 회피 용이
→ 멀웨어 업데이트 가능

키로거 (Keylogger):

키로거 동작 원리:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[사용자 키보드 입력]
    ↓
[후킹(Hook) 메커니즘]
    ↓
[입력 내용 기록]
├─ 타임스탬프
├─ 실행 중인 프로그램
└─ 입력 텍스트
    ↓
[로그 파일 생성]
    ↓
[정기적으로 외부 전송]

기록 예시:
2025-12-18 14:30:15 | chrome.exe | bank
2025-12-18 14:30:20 | chrome.exe | password123
2025-12-18 14:30:35 | chrome.exe | 1234-5678-9012-3456

랜섬웨어 (Ransomware):

랜섬웨어 공격 단계:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1단계: 침투
    ↓
[피싱 이메일 / 취약점 공격]
    ↓

2단계: 암호화
    ↓
[시스템 내 파일 스캔]
├─ 문서 (.doc, .pdf)
├─ 이미지 (.jpg, .png)
├─ 데이터베이스 (.db)
└─ 백업 파일
    ↓
[강력한 암호화 수행]
(AES-256, RSA-2048 등)
    ↓

3단계: 협박
    ↓
[화면에 협박 메시지 표시]
"당신의 파일이 암호화되었습니다.
비트코인 0.5 BTC를 보내면 복호화 키 제공.
72시간 내 미지불 시 파일 영구 삭제."
    ↓

4단계: 금전 요구
    ↓
[비트코인 주소 제공]
[결제 확인 페이지]

대표 사례:
• WannaCry (2017)
• Petya/NotPetya (2017)
• REvil (2021)

백도어 (Backdoor):

백도어 설치 및 활용:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[초기 침투]
    ↓
[백도어 설치]
├─ 새 관리자 계정 생성
├─ 원격 접속 포트 개방
└─ 방화벽 규칙 수정
    ↓
[정상 인증 우회]
    ↓
[공격자가 언제든지 접속 가능]
    ↓
[지속적인 악성 행위]
├─ 데이터 탈취
├─ 추가 멀웨어 설치
└─ 시스템 제어

특징:
→ 존재 은폐
→ 영구적 접근 권한
→ APT 공격에 활용

RAT (Remote Access Trojan):

RAT 기능:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[감염된 시스템]
    ↓
[RAT 설치]
    ↓
[C&C 서버 연결]
    ↓
[공격자 제어]
    ↓

제어 가능 기능:
├─ 파일 시스템 접근
├─ 화면 원격 조작
├─ 웹캠 활성화
├─ 마이크 녹음
├─ 키로깅
├─ 프로세스 제어
└─ 네트워크 스니핑

대표 RAT:
• DarkComet
• njRAT
• Poison Ivy

루트킷 (Rootkit):

루트킷 특징:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[루트킷 = 침입 도구 세트]
    ↓

포함 구성 요소:
├─ 다운로더
├─ 키로거
├─ 백도어
├─ RAT
└─ 은폐 도구
    ↓

은폐 메커니즘:
├─ 프로세스 목록에서 숨김
├─ 파일 시스템에서 숨김
├─ 레지스트리에서 숨김
├─ 네트워크 연결 숨김
└─ 커널 레벨 후킹
    ↓

탐지 어려움:
→ OS 깊은 곳에 설치
→ 관리자 도구도 속임
→ 전문 도구 필요

익스플로잇 (Exploit):

익스플로잇 공격 흐름:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[취약점 발견]
    ↓

취약점 유형:
├─ 버퍼 오버플로우
├─ SQL 인젝션
├─ 제로데이 취약점
└─ 권한 상승 취약점
    ↓

[익스플로잇 코드 작성]
    ↓
[취약점 공격 실행]
    ↓

공격 결과:
├─ 임의 코드 실행
├─ 권한 획득
├─ 인증 우회
└─ 서비스 거부
    ↓

[추가 멀웨어 설치]

예시:
• EternalBlue (WannaCry 사용)
• Shellshock (Bash 취약점)
• Heartbleed (OpenSSL 취약점)

75. 암호화 기술

암호화의 기본 개념

암호화 정의:

암호화 (Encryption):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[평문 (Plaintext)]
"Hello World"
    ↓
[암호화 알고리즘 + 키]
    ↓
[암호문 (Ciphertext)]
"5d41402abc4b2a76b9719d911017c592"
    ↓
[복호화 알고리즘 + 키]
    ↓
[평문 (Plaintext)]
"Hello World"

목적:
→ 데이터를 해독 불가능한 상태로 변환
→ 권한 없는 자의 접근 방지

암호화 구성 요소:

암호화 시스템 구성 요소:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. 알고리즘 (Algorithm)
   └─ 암호화 처리 절차 및 계산 방법
   └─ 공개되어도 안전해야 함

2. 키 (Key)
   └─ 알고리즘 계산에 사용하는 특정 값
   └─ 비밀로 유지되어야 함

3. 평문 (Plaintext)
   └─ 암호화 전 원본 데이터

4. 암호문 (Ciphertext)
   └─ 암호화 후 변환된 데이터

핵심 원칙:
→ 알고리즘이 알려져도 키 없이는 복호화 불가
→ 암호의 안전성은 키로 유지됨

암호화의 안전성:

Kerckhoffs의 원칙:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

"암호 시스템의 안전성은
알고리즘이 아닌 키의 비밀성에 의존해야 한다"

[알고리즘 공개]
    ↓
[보안 전문가들이 검증]
    ↓
[취약점 발견 및 개선]
    ↓
[안전한 알고리즘 확립]
    ↓
[오직 키만 비밀로 유지]
    ↓
[높은 보안성 확보]

나쁜 예: "내가 만든 비밀 알고리즘"
좋은 예: "검증된 AES 알고리즘 + 강력한 키"

해시 함수를 사용한 암호화

해시 함수 특징:

해시 함수 (Hash Function):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[입력 데이터]
"password123"
    ↓
[해시 함수]
(일방향 함수)
    ↓
[해시값 (고정 길이)]
"482c811da5d5b4bc6d497ffa98491e38"
    ↓
[복호화 불가능]

특징:
├─ 일방향성: 역산 불가
├─ 결정성: 같은 입력 → 같은 출력
├─ 고정 길이: 입력 크기 무관
├─ 눈사태 효과: 입력 1비트 변경 → 출력 완전히 변경
└─ 충돌 저항성: 같은 해시값 생성 어려움

해시 함수 vs 암호화:

해시 함수 활용 예시:

1. 비밀번호 저장:

비밀번호 저장 방식:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[사용자 회원가입]
    ↓
입력: "mypassword123"
    ↓
[서버: 해시 함수 적용]
해시: SHA-256("mypassword123")
결과: "8d969eef6ecad3c29a3a629280e686cf..."
    ↓
[DB 저장]
username: john
password: "8d969eef6ecad3c29a3a629280e686cf..."
    ↓

[사용자 로그인]
    ↓
입력: "mypassword123"
    ↓
[서버: 동일 해시 함수 적용]
해시: "8d969eef6ecad3c29a3a629280e686cf..."
    ↓
[DB 저장값과 비교]
    ↓
일치 → 로그인 성공

장점:
→ DB 유출되어도 원본 비밀번호 노출 안 됨
→ 관리자도 사용자 비밀번호 알 수 없음

2. 데이터 무결성 검증:

파일 무결성 검증:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[파일 다운로드 전]
    ↓
[서버에서 원본 파일 해시 계산]
file.zip → SHA-256 → "abc123def456..."
    ↓
[웹사이트에 해시값 게시]
    ↓

[사용자가 파일 다운로드]
    ↓
[다운로드한 파일 해시 계산]
downloaded.zip → SHA-256 → "abc123def456..."
    ↓
[해시값 비교]
    ↓
일치: 파일 무결, 변조 없음
불일치: 파일 손상 또는 변조됨

사용 사례:
• 소프트웨어 배포
• 블록체인
• Git 버전 관리

해시 함수에 솔트(Salt) 사용:

솔트를 이용한 보안 강화:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

문제: 동일 비밀번호 → 동일 해시값

사용자 A: "password123" → "abc123..."
사용자 B: "password123" → "abc123..."
    ↓
레인보우 테이블 공격에 취약

해결: 솔트(Salt) 추가

[회원가입]
    ↓
비밀번호: "password123"
    ↓
[랜덤 솔트 생성]
솔트: "x8Ks9mP2"
    ↓
[솔트 + 비밀번호 결합하여 해시]
해시: SHA-256("x8Ks9mP2" + "password123")
결과: "7f3d9c81ab4e2..."
    ↓
[DB 저장]
username: john
salt: "x8Ks9mP2"
password: "7f3d9c81ab4e2..."

결과:
→ 같은 비밀번호도 다른 해시값
→ 레인보우 테이블 공격 방어

주요 암호 알고리즘의 종류

암호화 방식별 알고리즘:

주요 암호 알고리즘:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[공통키 암호화 방식]
├─ AES (Advanced Encryption Standard)
│   └─ VPN, SSL/TLS, 파일 암호화
│
├─ RC4 (Rivest Cipher 4)
│   └─ WPA2, SSL (레거시)
│   └─ 현재는 취약점으로 사용 중단
│
└─ 3DES (Triple DES)
    └─ 레거시 시스템
    └─ AES로 대체 권장

[공개키 암호화 방식]
├─ RSA (Rivest-Shamir-Adleman)
│   └─ HTTPS, 전자서명
│   └─ 키 교환, 디지털 인증서
│
├─ DSA (Digital Signature Algorithm)
│   └─ 미국 정부 전자서명 표준
│   └─ 암호화 불가, 서명만 가능
│
├─ ECDSA (Elliptic Curve DSA)
│   └─ 타원곡선 암호화
│   └─ 블록체인 (Bitcoin, Ethereum)
│   └─ 짧은 키로 높은 보안
│
└─ ECC (Elliptic Curve Cryptography)
    └─ 모바일, IoT 기기
    └─ 효율적인 연산

[해시 함수]
├─ SHA-256 (Secure Hash Algorithm)
│   └─ 블록체인, 인증서
│
├─ SHA-3
│   └─ 최신 표준
│
└─ MD5 (Message Digest 5)
    └─ 취약점 발견, 사용 중단
    └─ 체크섬 용도로만 제한적 사용

알고리즘별 상세 설명:

AES (Advanced Encryption Standard):

AES 특징:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

채택 배경:
• 2001년 미국 표준으로 채택
• DES의 후속 표준

키 길이:
├─ AES-128: 128비트 키
├─ AES-192: 192비트 키
└─ AES-256: 256비트 키

강점:
✓ 빠른 속도
✓ 높은 보안성
✓ 하드웨어 가속 지원

사용처:
• VPN (IPsec, SSL VPN)
• 파일 암호화 (BitLocker, FileVault)
• 무선 LAN (WPA2, WPA3)
• HTTPS (TLS)

RC4:

RC4의 흥망성쇠:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[1987년]
    ↓
[RC4 개발]
간단하고 빠른 스트림 암호
    ↓

[1990-2000년대]
    ↓
[널리 사용]
• WEP (무선 LAN)
• WPA (초기)
• SSL/TLS
    ↓

[2013-2015년]
    ↓
[취약점 발견]
• BEAST 공격
• RC4 NOMORE 공격
    ↓

[현재]
    ↓
[사용 중단]
• TLS 1.3에서 제거
• WPA3로 대체

교훈:
→ 암호 알고리즘도 수명이 있음
→ 지속적인 보안 업데이트 필요

RSA:

RSA 암호화:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

기반 원리:
• 큰 소수의 곱셈은 쉬움
• 인수분해는 어려움

키 생성:
1. 큰 소수 p, q 선택
2. n = p × q
3. 공개키 (n, e)
4. 개인키 (n, d)

키 크기:
├─ 2048비트: 현재 권장
├─ 3072비트: 고보안
└─ 4096비트: 최고보안

사용처:
• HTTPS (TLS 핸드셰이크)
• SSH 키 인증
• 전자서명
• PGP/GPG 이메일 암호화

한계:
→ 느린 속도
→ 큰 데이터 암호화에 부적합
→ 주로 키 교환에 사용

ECDSA (타원곡선 암호):

ECDSA 장점:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

보안 강도 비교:
┌──────────┬──────────┬──────────┐
│ RSA      │ ECC      │ 보안 수준 │
├──────────┼──────────┼──────────┤
│ 3072비트 │ 256비트  │ 128비트   │
│ 7680비트 │ 384비트  │ 192비트   │
│ 15360비트│ 521비트  │ 256비트   │
└──────────┴──────────┴──────────┘

→ 짧은 키로 동등한 보안

사용 사례:
• Bitcoin: secp256k1 곡선
• Ethereum: secp256k1 곡선
• TLS 1.3: P-256, P-384 곡선
• 모바일 기기: 효율적 연산

블록체인에서의 활용:
[개인키 (256비트)]
    ↓
[ECDSA 서명]
    ↓
[트랜잭션 서명]
    ↓
[공개키로 검증]

76. 공통키 암호화 방식 / 공개키 암호화 방식

공통키 암호화 방식 (대칭키 암호화)

개념:

공통키 암호화 방식:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[송신자]                [수신자]
    \                    /
     \                  /
      \                /
       \              /
        [공통 비밀키]
       /              \
      /                \
     ↓                  ↓
 [암호화]            [복호화]
     ↓                  ↓
[암호문]  ────────→  [평문]

핵심:
→ 암호화와 복호화에 동일한 키 사용
→ 송수신자가 사전에 키 공유 필요

공통키 암호화 과정:

공통키 암호화 통신 흐름:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

사전 준비:
[키 생성]
    ↓
"SecretKey123"
    ↓
[안전한 채널로 키 공유]
송신자 ←─────────→ 수신자
    ↓

통신 단계:
[송신자]
    ↓
평문: "Hello"
    ↓
[AES 암호화 + SecretKey123]
    ↓
암호문: "5d41402a..."
    ↓
[네트워크 전송]
    ↓
[수신자]
    ↓
[AES 복호화 + SecretKey123]
    ↓
평문: "Hello"

장점과 단점:

공통키 암호화 장단점:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

장점:
✓ 빠른 속도
  └─ 대용량 데이터 암호화에 적합
✓ 간단한 알고리즘
✓ 적은 연산량

단점:
✗ 키 배송 문제 (Key Distribution Problem)
  └─ 네트워크로 키 전송 시 유출 위험
✗ 키 관리 복잡성
  └─ n명 통신 시 n(n-1)/2개 키 필요
  └─ 100명 → 4,950개 키
✗ 사전 키 공유 필요
  └─ 초기 연결 시 어려움

키 배송 문제:

공통키 암호화의 딜레마:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[송신자] ─────────── [수신자]
    │                    │
    └─→ [공통키 전송] ─→ │
            │
            ↓
        [공격자가
         중간에서
         키 탈취?]
            ↓
        [보안 파괴]

문제:
"암호화하려면 키가 필요한데,
키를 안전하게 전달하려면 암호화가 필요"

해결책:
→ 공개키 암호화 방식
→ Diffie-Hellman 키 교환
→ 대역 외 전달 (Out-of-band)

공개키 암호화 방식 (비대칭키 암호화)

개념:

공개키 암호화 방식:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[송신자]            [수신자]
                         │
                    [키 쌍 생성]
                    /         \
            [공개키]           [개인키]
         (Public Key)       (Private Key)
              │                  │
              │                  │
    [네트워크로 공개]      [비밀로 보관]
              ↓                  │
              │                  │
[송신자가 공개키로 암호화]        │
              ↓                  │
         [암호문]                │
              │                  │
              └────→ [수신자가 개인키로 복호화]
                                 ↓
                            [평문 복원]

핵심:
→ 암호화 키 ≠ 복호화 키
→ 공개키로 암호화, 개인키로만 복호화

통신 과정:

공개키 암호화 통신 흐름:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. 키 생성 및 배포:
[수신자 Bob]
    ↓
[RSA 키 쌍 생성]
├─ 공개키 (n, e)
└─ 개인키 (n, d)
    ↓
[공개키를 웹사이트에 게시]
    ↓

2. 암호화 및 전송:
[송신자 Alice]
    ↓
[Bob의 공개키 다운로드]
    ↓
평문: "비밀 메시지"
    ↓
[RSA 암호화 + Bob 공개키]
    ↓
암호문: "8f3e9d2a..."
    ↓
[네트워크 전송]
    ↓

3. 복호화:
[수신자 Bob]
    ↓
[자신의 개인키로 복호화]
    ↓
평문: "비밀 메시지"

안전성:
→ 공개키가 유출되어도 안전
→ 개인키 없이는 복호화 불가

장점과 단점:

공개키 암호화 장단점:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

장점:
✓ 키 배송 문제 해결
  └─ 공개키는 안전하게 공개 가능
✓ 키 관리 단순
  └─ n명 통신 시 2n개 키만 필요
  └─ 100명 → 200개 키
✓ 사전 키 공유 불필요
  └─ 즉시 암호화 통신 가능
✓ 전자서명 가능

단점:
✗ 느린 속도
  └─ 공통키 방식의 수백~수천 배 느림
✗ 복잡한 수학 연산
✗ 큰 데이터 암호화 부적합
✗ 공개키 인증 필요
  └─ MITM 공격 방지

공통키 vs 공개키 비교:

하이브리드 암호화 시스템

실무에서의 활용:

하이브리드 암호화 (HTTPS 예시):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[클라이언트]           [서버]
                         │
1. 핸드셰이크:          │
    │                   │
    ├─→ [서버 공개키 요청]
    │                   │
    │←─ [서버 공개키 전송]
    │      (RSA 공개키)
    │                   │
    ├─→ [공통키 생성 및 암호화]
    │    공통키: AES-256
    │    공개키로 암호화
    │    전송
    │                   │
    │                   [개인키로 복호화]
    │                   공통키 획득
    │                   │

2. 데이터 전송:
    │                   │
    ├─→ [HTTP 요청]
    │   AES-256 암호화
    │                   │
    │←─ [HTTP 응답]
    │   AES-256 암호화
    │                   │

장점 결합:
→ 공개키: 안전한 키 교환
→ 공통키: 빠른 데이터 암호화

과정 상세:

HTTPS 연결 상세 흐름:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1단계: 서버 인증 및 공개키 전달
[클라이언트] → "ClientHello" → [서버]
[클라이언트] ← "ServerHello + 인증서" ← [서버]
                (서버 공개키 포함)

2단계: 세션 키 생성 및 교환
[클라이언트]
    ↓
[난수 생성] → 이것이 세션 키 (AES 키)
    ↓
[서버 공개키로 암호화]
    ↓
[암호화된 세션 키 전송] → [서버]
                          ↓
                    [개인키로 복호화]
                          ↓
                    [세션 키 획득]

3단계: 세션 키로 통신
[클라이언트] ←─ AES 암호화 ─→ [서버]
              (빠른 속도)

세션 종료 시:
세션 키 폐기 → 다음 연결 시 새 키 생성

공개키 암호화 방식을 역으로 사용한 전자 서명

전자 서명 원리:

전자 서명 (Digital Signature):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

일반 공개키 암호화:
[송신자] → 수신자 공개키로 암호화 → [수신자]
           수신자 개인키로 복호화

전자 서명 (역방향):
[송신자] → 자신의 개인키로 "서명" → [수신자]
           송신자 공개키로 "검증"

목적:
→ 기밀성 (X)
→ 인증성 (O): 송신자 신원 확인
→ 무결성 (O): 데이터 변조 방지
→ 부인 방지 (O): 송신 사실 부정 불가

전자 서명 과정:

전자 서명 생성 및 검증:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[송신자 Alice]
    ↓
[문서]
"계약서 내용"
    ↓
[해시 함수]
SHA-256
    ↓
[문서 해시값]
"3f4d8a2b..."
    ↓
[Alice 개인키로 암호화]
RSA 개인키
    ↓
[전자 서명]
"9e2f1c8d..."
    ↓
[문서 + 서명 전송]
    ↓
[수신자 Bob]
    ↓
    ├─→ [받은 문서]
    │   "계약서 내용"
    │       ↓
    │   [해시 계산]
    │   "3f4d8a2b..."  ───┐
    │                     │
    └─→ [받은 서명]        │
        "9e2f1c8d..."     │
            ↓              │
        [Alice 공개키로    │
         복호화]           │
            ↓              │
        [원본 해시값]      │
        "3f4d8a2b..." ─────┤
                          │
                          ↓
                      [비교]
                          ↓
                    일치 → 검증 성공
                    불일치 → 변조됨

전자 서명의 보안 원리:

전자 서명의 보안성:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[Alice 개인키로 서명]
    ↓
오직 Alice만 서명 생성 가능
    ↓
[Alice 공개키로 검증]
    ↓
누구나 검증 가능
    ↓
검증 성공 = Alice가 서명했음을 증명

위조 방지:
• 개인키 없이는 유효한 서명 생성 불가
• 문서 변조 시 해시값 변경 → 검증 실패
• 서명 변조 시 공개키로 복호화 실패

활용:
• 전자계약
• 소프트웨어 배포 (코드 서명)
• 이메일 (S/MIME, PGP)
• PDF 서명
• 블록체인 트랜잭션

인증 기관의 역할:

공개키 인증:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

문제 상황:
[Alice] → "이것이 내 공개키야" → [Bob]
              ↑
          [공격자가 가짜 공개키를 끼워넣으면?]

해결: 인증 기관 (CA)
[Alice]
    ↓
[인증 기관에 신원 확인 및 공개키 등록]
    ↓
[CA가 Alice 공개키에 전자 서명]
    ↓
[인증서 발급]
    ↓

[Alice] → [인증서 전송] → [Bob]
                           ↓
                       [CA 공개키로
                        인증서 검증]
                           ↓
                       [Alice 공개키가
                        진짜임을 확인]

인증서 내용:
• 소유자 정보 (Alice)
• 공개키
• CA의 전자 서명
• 유효 기간

77. 서버 인증서 / 인증 기관

본인 인증을 위한 서버 인증서

서버 인증서의 필요성:

웹 통신의 두 가지 보안 요구사항:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. 통신 암호화
   └─ 데이터 도청 방지

2. 상대방 인증
   └─ 피싱 사이트 방지

[사용자]
    ↓
"https://mybank.com에 접속"
    ↓

의문:
• 정말 mybank.com이 맞나?
• 공격자가 만든 가짜 사이트는 아닐까?
• 입력한 비밀번호가 안전할까?
    ↓

[서버 인증서로 검증]
    ↓

확인 사항:
✓ 서버가 mybank.com 맞음
✓ 인증 기관이 신원 확인함
✓ 암호화 통신 가능

서버 인증서 동작 원리:

서버 인증서 검증 과정:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[웹 브라우저]                [웹 서버]
    │                          │
    ├─→ HTTPS 연결 요청 ────→│
    │                          │
    │                     [서버 인증서
    │                      + 공개키 전송]
    │                          │
    │←─ 서버 인증서 수신 ────│
    ↓                          │
[인증서 검증]                  │
    │                          │
    ├─ 발급자 확인              │
    │  (신뢰할 수 있는 CA?)     │
    │                          │
    ├─ 유효 기간 확인           │
    │  (만료되지 않았나?)       │
    │                          │
    ├─ 도메인 일치 확인         │
    │  (요청한 도메인과 일치?)  │
    │                          │
    ├─ CA 서명 검증            │
    │  (위조되지 않았나?)       │
    │                          │
    ↓                          │
[검증 성공]                    │
    │                          │
    ├─→ 암호화 통신 시작 ───→│
    │                          │
    │←─→  안전한 HTTPS 통신  ←→│

서버 인증서 구성 요소:

서버 인증서 내용:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[인증서 정보]
├─ 버전: v3
├─ 일련번호: 1234567890abcdef
├─ 서명 알고리즘: SHA-256 with RSA
│
├─ 발급자 (Issuer):
│   └─ CN=DigiCert Global Root CA
│   └─ O=DigiCert Inc
│
├─ 유효 기간:
│   ├─ 시작: 2024-01-01
│   └─ 종료: 2025-12-31
│
├─ 주체 (Subject):
│   ├─ CN=mybank.com
│   ├─ O=MyBank Inc.
│   └─ C=KR
│
├─ 공개키 정보:
│   ├─ 알고리즘: RSA
│   ├─ 키 크기: 2048 bits
│   └─ 공개키 값: (RSA Public Key)
│
└─ CA의 전자 서명
    └─ (CA 개인키로 서명)

확장 필드:
├─ Subject Alternative Name (SAN):
│   ├─ mybank.com
│   ├─ www.mybank.com
│   └─ *.mybank.com (와일드카드)
│
└─ Key Usage:
    └─ Digital Signature, Key Encipherment

서버 인증서를 발행하는 인증 기관

인증 기관 (CA):

인증 기관 (Certificate Authority):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

역할:
├─ 신원 확인
│   └─ 기업 실존 여부 검증
│   └─ 도메인 소유권 확인
│
├─ 인증서 발급
│   └─ 서버 공개키에 CA 서명
│
├─ 인증서 관리
│   └─ 갱신, 폐기 관리
│
└─ 신뢰 체계 유지
    └─ 루트 인증서 관리

대표 CA:
• DigiCert
• Let's Encrypt (무료)
• GlobalSign
• Comodo
• GeoTrust

인증서 발급 과정:

기업의 HTTPS 지원 절차:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[기업: MyBank]
    ↓

1단계: 준비
[키 쌍 생성]
├─ 개인키 (비밀 보관)
└─ 공개키
    ↓
[CSR 생성]
(Certificate Signing Request)
├─ 기업 정보
├─ 도메인: mybank.com
└─ 공개키
    ↓

2단계: 인증 기관 신청
[CA에 CSR 제출]
    ↓
[신원 확인 과정]
├─ 등기부등본 확인
├─ 대면/전화 확인
├─ 도메인 소유권 확인
│   └─ DNS 레코드 추가
│   └─ 특정 파일 호스팅
└─ 사업자 등록증 확인
    ↓

3단계: 인증서 발급
[CA가 확인 완료]
    ↓
[CA 개인키로 서명]
    ↓
[서버 인증서 발급]
├─ 공개키
├─ 기업 정보
└─ CA 서명
    ↓

4단계: 서버 설치
[웹 서버에 인증서 + 개인키 설치]
├─ 인증서: /etc/ssl/certs/mybank.crt
└─ 개인키: /etc/ssl/private/mybank.key
    ↓
[HTTPS 서비스 시작]

인증서 검증 레벨:

인증서 검증 레벨:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[DV - Domain Validation]
├─ 검증: 도메인 소유권만
├─ 발급 시간: 수분~수시간
├─ 가격: 무료~저렴
├─ 용도: 개인 블로그, 소규모 사이트
└─ 예: Let's Encrypt
    ↓

[OV - Organization Validation]
├─ 검증: 도메인 + 기업 실존
├─ 발급 시간: 1~3일
├─ 가격: 중간
├─ 용도: 기업 웹사이트
└─ 인증서에 기업 정보 표시
    ↓

[EV - Extended Validation]
├─ 검증: 도메인 + 엄격한 기업 검증
├─ 발급 시간: 1~2주
├─ 가격: 비쌈
├─ 용도: 금융, 전자상거래
└─ 주소창에 기업명 표시 (과거)

현재 추세:
→ DV 인증서 대중화 (Let's Encrypt)
→ EV 인증서의 UI 혜택 감소
→ HTTPS는 필수, 인증 레벨은 선택

HTTPS 통신의 기능인 암호화 통신과 웹 사이트의 실체 인증

HTTPS의 두 가지 핵심 기능:

HTTPS 통신의 이중 목적:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[HTTPS 통신]
    │
    ├─→ 1. 암호화 통신
    │      └─ 데이터 도청 방지
    │      └─ 중간자 공격 방지
    │      └─ 데이터 무결성 보장
    │
    └─→ 2. 웹 사이트 실체 인증
           └─ 서버 신원 확인
           └─ 피싱 사이트 방지
           └─ 신뢰성 확보

과거 vs 현재:

HTTPS 사용의 변화:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[과거 - 선택적 사용]
    │
    ├─ 일반 페이지: HTTP
    │   └─ 암호화 불필요
    │
    └─ 민감 페이지: HTTPS
        └─ 로그인 페이지
        └─ 결제 페이지
        └─ 개인정보 입력

문제점:
• HTTP 페이지에서 쿠키 도청
• 혼합 콘텐츠 (Mixed Content) 취약점
• 사용자 혼란

────────────────────────────

[현재 - 전체 적용]
    │
    └─ 모든 페이지: HTTPS
        └─ 전체 사이트 암호화

이유:
✓ Let's Encrypt로 무료 인증서
✓ 성능 영향 최소화 (HTTP/2, TLS 1.3)
✓ SEO 이점 (Google 순위 요소)
✓ 브라우저 경고 (HTTP는 "안전하지 않음")
✓ 법적 요구사항 (GDPR 등)

브라우저의 HTTPS 표시:

브라우저 주소창 표시:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

HTTPS (유효한 인증서):
┌────────────────────────────┐
│ 🔒 https://mybank.com      │
└────────────────────────────┘
"안전함" 또는 자물쇠 아이콘

HTTPS (문제 있는 인증서):
┌────────────────────────────┐
│ ⚠️ https://suspicious.com  │
└────────────────────────────┘
"주의 필요" 경고

HTTP (암호화 없음):
┌────────────────────────────┐
│ ⓘ http://oldsite.com       │
└────────────────────────────┘
"안전하지 않음" 경고

인증서 정보 확인:
자물쇠 아이콘 클릭
    ↓
인증서 보기
    ↓
• 발급 대상
• 발급자 (CA)
• 유효 기간
• 공개키 정보

무료 인증서의 등장:

Let's Encrypt의 영향:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[2016년 이전]
    │
    └─ HTTPS는 비용 부담
        ├─ 연간 수만~수십만 원
        └─ 중소 사이트 부담

[2016년 Let's Encrypt 등장]
    │
    └─ 무료 DV 인증서
        ├─ 자동 발급
        ├─ 자동 갱신 (90일마다)
        └─ 오픈소스 도구 (Certbot)

결과:
• HTTPS 사용률 급증
• 2016년: ~40%
• 2025년: ~95% (주요 사이트)

현대 HTTPS의 의미 변화:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

과거: "이 사이트는 신뢰할 수 있다"
    ↓
현재: "이 사이트는 기본 보안을 갖췄다"

암호화 통신 = 필수 (표준)
실체 인증 = 선택 (OV, EV)

사용자 주의사항:
→ HTTPS라고 무조건 안전한 것은 아님
→ 피싱 사이트도 HTTPS 사용 가능
→ 도메인 이름 확인 필수
→ 주소창 전체 URL 확인

인증서 폐기:

인증서 폐기 (Certificate Revocation):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

폐기 사유:
├─ 개인키 유출
├─ 기업 정보 변경
├─ 도메인 소유권 상실
└─ 보안 침해

폐기 확인 방법:

1. CRL (Certificate Revocation List)
[브라우저]
    ↓
[CA에서 폐기 목록 다운로드]
    ↓
[인증서가 목록에 있는지 확인]

단점: 목록이 커짐, 느림

2. OCSP (Online Certificate Status Protocol)
[브라우저]
    ↓
[CA에 실시간 조회]
"이 인증서 유효한가요?"
    ↓
[CA 응답]
"유효함" / "폐기됨" / "알 수 없음"

단점: 개인정보 노출, CA 부하

3. OCSP Stapling
[웹 서버가 주기적으로 OCSP 응답 받음]
    ↓
[클라이언트에게 함께 전송]
    ↓
[클라이언트는 CA 조회 불필요]

장점: 빠름, 개인정보 보호

핵심 요약:

서버 인증서와 인증 기관 요약:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[인증서]
├─ 서버의 신원을 증명하는 디지털 문서
├─ 공개키 포함
└─ CA의 전자 서명

[인증 기관]
├─ 신원 확인 및 인증서 발급
├─ 신뢰의 근간
└─ 브라우저에 루트 인증서 사전 설치

[HTTPS 통신]
├─ 암호화: 데이터 보호
└─ 인증: 신원 확인

[현대적 접근]
├─ 모든 웹사이트 HTTPS 필수
├─ Let's Encrypt로 무료화
└─ 암호화 기능이 주, 인증은 부가

보안 의식:
→ HTTPS ≠ 절대 안전
→ 도메인 이름 항상 확인
→ 의심스러운 인증서 경고 무시 금지